|
|
|
|
|
|
|
Build-and-fix model |
|
Waterfall model |
|
Rapid prototyping model |
|
Incremental model |
|
Extreme programming |
|
Synchronize-and-stabilize model |
|
Spiral model |
|
Object-oriented life-cycle models |
|
Comparison of life-cycle models |
|
|
|
|
|
|
|
Life-cycle model (formerly, process model) |
|
The steps through which the product progresses |
|
Requirements phase |
|
Specification phase |
|
Design phase |
|
Implementation phase |
|
Integration phase |
|
Maintenance phase |
|
Retirement |
|
|
|
|
|
Problems |
|
No specifications |
|
No design |
|
Totally unsatisfactory |
|
Need life-cycle model |
|
“Game plan” |
|
Phases |
|
Milestones |
|
|
|
|
|
|
Characterized by |
|
Feedback loops |
|
Documentation-driven |
|
Advantages |
|
Documentation |
|
Maintenance easier |
|
Disadvantages |
|
Specifications |
|
Joe and Jane Johnson |
|
Mark Marberry |
|
|
|
|
|
|
|
Do not turn into product |
|
Rapid prototyping may replace specification
phase—never the design phase |
|
Comparison: |
|
Waterfall model—try to get it right first time |
|
Rapid prototyping—frequent change, then discard |
|
|
|
|
|
Waterfall model |
|
Many successes |
|
Client needs |
|
Rapid prototyping model |
|
Not proved |
|
Has own problems |
|
Solution |
|
Rapid prototyping for requirements phase |
|
Waterfall for rest of life cycle |
|
|
|
|
Divide project into builds |
|
|
|
|
|
Waterfall, rapid prototyping models |
|
Operational quality complete product at end |
|
Incremental model |
|
Operational quality portion of product within
weeks |
|
Less traumatic |
|
Smaller capital outlay, rapid return on
investment |
|
Need open architecture—maintenance implications |
|
Variations used in object-oriented life cycle |
|
|
|
|
|
Problems |
|
Build-and-fix danger |
|
Contradiction in terms |
|
|
|
|
|
More risky version—pieces may not fit |
|
CABTAB and its dangers |
|
|
|
|
Somewhat controversial new approach |
|
Stories (features client wants) |
|
Estimate duration and cost of each story |
|
Select stories for next build |
|
Each build is divided into tasks |
|
Test cases for task are drawn up first |
|
Pair programming |
|
Continuous integration of tasks |
|
|
|
|
Computers are put in center of large room lined
with cubicles |
|
Client representative is always present |
|
Cannot work overtime for 2 successive weeks |
|
No specialization |
|
Refactoring |
|
|
|
|
XP has had some successes |
|
Good when requirements are vague or changing |
|
Too soon to evaluate XP |
|
|
|
|
|
|
Microsoft’s life-cycle model |
|
Requirements analysis—interview potential
customers |
|
Draw up specifications |
|
Divide project into 3 or 4 builds |
|
Each build is carried out by small teams working
in parallel |
|
|
|
|
|
At the end of the day—synchronize (test and
debug) |
|
At the end of the build—stabilize (freeze build) |
|
Components always work together |
|
Get early insights into operation of product |
|
|
|
|
|
Simplified form |
|
Waterfall model plus risk analysis |
|
Precede each phase by |
|
Alternatives |
|
Risk analysis |
|
Follow each phase by |
|
Evaluation |
|
Planning of next phase |
|
|
|
|
If risks cannot be resolved, project is
immediately terminated |
|
|
|
|
Radial dimension: cumulative cost to date |
|
Angular dimension: progress through the spiral |
|
|
|
|
|
|
|
Strengths |
|
Easy to judge how much to test |
|
No distinction between development, maintenance |
|
|
|
Weaknesses |
|
For large-scale software only |
|
For internal (in-house) software only |
|
|
|
|
|
Need for iteration within and between phases |
|
Fountain model |
|
Recursive/parallel life cycle |
|
Round-trip gestalt |
|
Unified software development process |
|
All incorporate some form of |
|
Iteration |
|
Parallelism |
|
Incremental development |
|
Danger |
|
CABTAB |
|
|
|
|
Features |
|
Overlap (parallelism) |
|
Arrows (iteration) |
|
Smaller maintenance circle |
|
|
|
|
|
Different life-cycle models |
|
Each with own strengths |
|
Each with own weaknesses |
|
Criteria for deciding on a model include |
|
The organization |
|
Its management |
|
Skills of the employees |
|
The nature of the product |
|
Best suggestion |
|
“Mix-and-match” life-cycle model |
|
|
|